Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/879

Internet Message Format | 1994-08-27 | 8KB

Date: Tue, 19 Jul 1994 22:57:06 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Amodal, etc.
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407192206.A23061-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Hollis:

]GEM is not going to change to match my philosophy; so we're writing a
]GEM Library to *match* the philosophy. There is no reason why users have to
]be stuck in the dark ages in terms of a user interface.

Did you ever consider that perhaps some people won't LIKE your
philosophy?  Some won't, some won't.

I'm writing an amodal dialog handler, and there will be options that the
developer can set to make it disabled, an untoppable tool box, operable
even while not on top, etc.

But the default will be that only the TOP window is operable because it
has the focus (although it always processes WM_CLOSE, etc. from MultiTOS,
et al, even while not on top).

Besides, when you have the window on top, the WHOLE window is visible and
there is only one rectangle in the window's rectangle list.  You can do
things more efficiently if you don't have to break them up, clip multiple
areas in succession, etc.


Side note:

Have you noticed that MultiTOS does not combine multiple window redraw
messages even if one's contained in the other?  Two overlapping redraw
requests will cause the same area to be redrawn twice.

And have you also noticed that it doesn't optimize the rectangle list
like WINX does?  If two adjacent rectangles have, say, the same width,
and one's top meets the other's bottom, MultiTOS will put two rectangles
in the list.  I like the way WINX optimizes this all.


Another note:

Bickering is counterproductive.  Just imagine an outsider watching the
synde remarks, insults and other nasty things being thrown around... he'd
never want to follow our standard, one created by a bunch of
argumentative 12 year-olds.


Hollis:

]We *did* do it right. If you had a copy of the demo program and used it, you
]would never be able to tell that we do these so-called "time wasting"
things,
]unless we told you.

Time-wasting is time-wasting.  Period.  If you're writing part of an OS,
you can optimize something, you can fit in the code, and you don't do it,
you're an idiot. Not that I'm calling you or anyone else an idiot.

If you checked the mouse position, say, every 1/2 second this would be
much better than busy-tracking it, and the user could care less about a
1/2 second delay before his mouse-pointer changed.

On the other hand, finding the largest possible rectangle that the mouse
pointer can move in before it enters or exits an object that would change
the pointer or something like that is most efficient because it lets the
OS, at the lowest level, track the mouse, rather than having your program
call objc_find every time the mouse pointer moved, which is wasteful.

At this point, my amodal dialog handler doesn't change the mouse pointer
for anything, and I'm not too enthusiastic about it because all the
problems associated with other applications wanting to change it, etc,
plus I never cared about seeing it change.  I can position things more
comfortably with the pointer than with the cross hairs, text-cursor or
whatever.

If I put it in at all, though, waiting for a rectangle event would make
the interface to my routines more complicated, defeating my push toward
simplicity for the programmer, so I would probably check the mouse
position every time the service routine for the dialog is called so the
developer can set up a timer event.


I do not like the idea of having buttons function in background windows
unless that particular dialog is INTENDED to work that way.  There should
be options for doing this for things like tool boxes and multiple
non-overlapping pannels, but otherwise, I like the way GEM works normally.


Oh, BTW, I wish you luck on your amodal dialog libraries.  It'll be a
long time before mine are as powerful as yours, but hopefully my
competition will do you some good.  :)


I couldn't possibly do WITHOUT extended object types.  I was kinda
surprised that WERCS supported them.  :)  You know what I HATE about
WERCS?  Not only does it squack at you when you overlap two objects, but
IT DOESN'T LET YOU.  Very irritating.


I agree that MultiTOS is seriously unbearably slow.


Have you seen OMEn?  That screen font gives me a massive headache.  Does
this guy have a clue about user iterfaces?  Someone should give him a
lecture on aesthetics.


What precisely are you referring to when you talk about multi-threading
in the context of your dialog libraries?


How do you handle your sliders?  How does the developer construct one in
a dialog?


Forget:

]>For the program source code, there is little to worry about.  If the
]>slider position and size in the resource file do not correspond to the
]>numbers you placed in the parent BOXTEXT, then you can kick them into
]>place by calling a routine immediately after you initialize the dialog.
]
]When you say slider, what do you mean?  The kind that just allows you to
]move a small box to a position within another box (like a window slider)
]or an active slider that scrolls through a list of items?  In general,
]I think your idea is interesting.  Not _too_ complicated, but on the
]other hand setting it up the first time could be a little slow (though
]this is not unusual -- everything has a learning curve).

Only the window-like sliders are available right now, although active
sliders will be shortly.  The only difference is that as the slider is
dragged, messages will be returned to the application so that the
developer can update the displayu of something else on the fly.

Every amodal handler is going to have complication SOMEWHERE.  There is
always going to be something to complain about, but it will be different
for each library.  Mine puts more into the setup in the resource editor
so that the programmer has to do much less in his source code.


]>                    I intend to release my source code for use by Atari
]>developers, although I have not determined how I will handle
]>compensation.  (I could charge developers who use it a small one-time fee.)
]
]This could be a problem; I can only speak for myself, but if there is
]a choice between a free product and one that I would have to pay for
]to use, I'll usually use the free one (unless the one that I have to
]pay for is unique).  EGEM is free; my own dialog-library (though not
]as good as EGEM) is free for anyone who asks.  I like your idea, but
]probably not enough to pay for it...  :)

I'm broke.  I need any money I can get, especially for something that
would be so widely used.  :)

I hope to put enough functionality into my library so as to make it a
serious contender against the others.


Do you have any suggestions on how I should store accelerator keys for
buttons in dialogs?  I thought of obscuring a parent object behind every
object that contained short-cut info, and a few other things.

The easiest way, for me, would be to have the programmer pass an array of
accelerators to the dialog initialization routine with enough information
to know which buttons to deal with and where to put the little underline
thingys, but this would require code changes when something needs to be
modified, so it's out of the question.  What do you think?


Ssykor:

I tried to uudecode the fontselector you put in your email.  It wouldn't
decode.  The program says something about no end of line.